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METHODS AND APPARATUS FOR AUTOMATICALLY EXCHANGING 

CREDIT INFORMATION 

5 

RELATED APPLICATION 

This application claims priority under 35 U.S.C. § 1 19(e) from Provisional 
Application Serial No. 60/248,290, filed November 14, 2000. 

10 

FIELD OF THE INVENTION 

The invention relates generally to credit information, and, more particularly, to 
methods and apparatus for developing and selling commercial lending information. 

15 BACKGROUND OF THE INVENTION 

Today, credit bureau reports do not include information about an entity’s loan 
and/or lease obligations and payment history. Loans and/or leases of interest can be, 
for example, real property loans and/or leases and/or personal property loans and/or 
leases. While commercial lending companies can currently determine the number of 
20 loans and/or leases a customer has with that lender and/or lessor by using their own 

lending systems, a commercial lending company cannot determine the total number of 
loans and/or leases a customer has, including loans and/or leases with other lenders 
and/or lessors and their respective payment histories. Therefore, lenders and/or 
lessors perform manual checks by gathering D&B reports and checking the 
25 applicants’ payment history with other commercial lending companies through a 

manual phone call. This method for checking payment history information is 
inefficient because it is extremely time consuming and can diminish the 
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confidentiality of the potential loan and/or lease agreement. In addition, because this 
method is so time consuming, it is also rather ineffective because lenders and/or 
lessors do not want to take the time to properly check loan and/or lease references. 

This method is undesirable since it results in a number of inefficiencies including high 
5 costs to process applications, lost transactions since many borrowers are denied credit 

due to lack of information, and high operating costs to maintain staff to make manual 
telephone calls. There is reluctance among lenders and/or lessors to check credit 
references with other lenders and/or lessors for fear of opening the deal up to 
competition. Accordingly, credit decisions are made many times based upon 
10 incomplete information, which can result in one of two undesirable scenarios: either 

an unrecoverable loan is granted, or an applicant who could ultimately satisfy the 
payment schedule is denied a loan and/or lease. Lenders and/or lessors have 
traditionally entered into loans and/or leases despite this lack of information because 
lenders and/or lessors would rather accept less creditworthy deals than make no deals 
15 in an effort to maintain volume and profitability. 

Despite the aforementioned problem, lenders and/or lessors have continued 
using the manual method for lack of a better alternative and because lenders and/or 
lessors currently have no facility for obtaining a comprehensive view of the 
applicant’s leases and loans with other lenders. 

20 As used herein, “lender” includes a lessor, as well as a party more traditionally 

thought of as a lender, e.g., a loaner of money. As used herein, “lease” or “loan” are 
used interchangeably. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is an illustration of an exemplary apparatus constructed in accordance 
with the teachings of the invention and shown in a preferred environment of use. 

FIG. 2 is a more detailed view of the apparatus of FIG. 1. 

5 FIG. 3 is a more detailed view of the data processing facility of FIG. 2. 

FIGS. 4-5 are an illustration of exemplary software that can be used to 
implement the apparatus of FIGS. 1 and 2. 

FIG. 6 is an illustration of exemplary software for implementing the loading 
process of FIG. 10. 

10 FIG. 7 is an additional illustration of exemplary software for implementing the 

loading process of FIG. 10. 

FIG. 8 is a detailed view of the executable programs in the exemplary 
software of FIG. 7. 

FIG. 9 is a detailed view of the executable programs in the exemplary 

15 software of FIG. 8. 

FIG. 10 is an illustration of exemplary software that can be used to implement 
the apparatus of FIGS. 1 and 2. 

FIG. 11 is an illustration of an exemplary payment history data file. 

FIG. 12 is a more detailed view of the data loading process of FIG. 10. 

20 FIG. 13 is an illustration of exemplary software for implementing the user 

identifier of FIG. 2. 

FIG. 14 is an illustration of exemplary software for implementing the search 
engine of FIG. 2. 
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FIGS. 15 A-E are an illustration of an exemplary payment history report 
generated by an apparatus of FIGS. 1 and 2. 

FIG. 16 is an illustration of exemplary software for implementing the 
accounting facility of FIG. 2. 

5 

DFTATT .KD DESCRIPTION OF PREFERRED EMBODIMENTS 
A. Overview 

Commercial lending companies become Members to the credit information 
service. In becoming a Member, the commercial lending companies agree to provide 
10 their experience regarding their customers’ credit and business information, such as 

one or more of their current lease and/or loan obligations and payment history. This 
information may include leases, loans, lines of credit and business information. 
Members will be able to inquire about customers, such as borrowers and/or lessees, in 
the system (regardless of which commercial lending company provided the data) and 
15 retrieve payment history reports for any of the customers’ outstanding loans and/or 

leases. Anonymity is maintained so that an inquirer cannot identify the lender, and 
unauthorized users are prevented from accessing payment history information. 
Members are then charged for these inquiry transactions. 

20 B. System 

FIG. 1 illustrates an exemplary apparatus 10 constructed in accordance with 
the teachings of the invention for automatically exchanging credit information. As 
shown in FIG. 1, the disclosed credit information apparatus 10 is preferably 
implemented by a computer coupled to the Internet 12. However, persons of ordinary 
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skill in the art will readily appreciate that the teachings of the invention are in no way 
limited to use with the Internet or to any other particular environment of use. 
Nonetheless, the credit information apparatus 10 is preferably implemented by a 
conventional server programmed to communicate over the Internet using conventional 
5 communication protocols (e.g., HTTP/IP). Optionally, more than one computer can 

be used to implement the credit information apparatus 10. 

As also shown in FIG. 1, lenders and/or finance companies 14, 16, 18, 20 
preferably also have access to computers by which they can access the Internet 12 for 
communication with the credit information apparatus 10. Such lender and/or finance 
10 company computers 14, 16, 18, 20 can be implemented by any known computing 

device, for example, a personal computer, and can connect to the Internet in any 
conventional manner (e.g., through a cable modem, a telephone line, a wireless 
connection, etc). As mentioned above, each of the lenders and/or finance companies 
14, 16, 18, 20 can contact the credit information apparatus 10 to upload data from its 
15 own database concerning, for example, the credit history of its customers and/or to 

search for and download credit data concerning customers (or potential customers) of 
interest. In this way, lenders and/or finance companies (which may be competitors) 
are provided with a mechanism to share and/or pool credit history data without 
revealing information to competitors that could be used to their detriment. 

20 A more detailed view of the apparatus 10 for pooling lease credit information 

is shown in FIG. 2. As shown in that figure, the apparatus 10 includes an input 24. 
The input 24 can be implemented by any conventional device known in the art (e.g., a 
modem, a keyboard, a mouse, etc.) 
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As shown in FIG. 2, the apparatus 10 is provided with a conventional data 
storage device 26. The data storage device 26 can also be implemented by any known 
device capable of storing the credit information received from the input device 24. 

For example, the data storage device 26 can be implemented by a hard disk drive or a 
5 tape drive. 

For the purpose of limiting access to the credit information stored in the data 
storage device 26, the apparatus 10 is further provided with a user identifier 28. The 
user identifier 28 has access to administrative data stored in the data storage device 
26. In particular, when a user accesses the apparatus via input 24, the user is asked to 
10 enter a user name and/or a password. The user identifier 28 scans the administrative 

data stored in the data storage device 26 for the user name and/or password to verify 
that the user is authorized to access the apparatus 10. If the user is not recognized by 
the user identifier 28, an error message is sent and the user will not be able to access 
the credit information stored in the apparatus 10. Preferably, users which are not 
15 recognized by the user identifier 28 will also be prevented from inputting data into the 

apparatus 10 to prevent vandalism. If the user is recognized by the user identifier 28, 
the user will be able to access the credit information stored in the apparatus 10. 

For the purposes of processing credit in f ormation received at the input 24 

from the user recognized by the user identifier 28, the apparatus 10 is further provided 

20 with a data processing facility 30. As shown in FIG. 3, the data processing facility 30 

includes a data validator 32 and a record formatter 34. The data validator 32 is 

structured to test the credit information received via input 24 for validity. The record 

formatter 34 is structured to convert the credit information received via input 24 to a 

predetermined format for storage in the data storage device 26. The data validator 32 
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and the record formatter 34, therefore, cooperate to ensure that the data storage device 
26 includes only valid data that has been formatted for searching and use by the 
apparatus 10. The tests performed by the data validator 32 will be explained in 
further detail below. Preferably, however, the data validator 32 tests the credit 
5 information by comparing it to prior credit information which has previously been 

stored in the data storage device 26. 

In order to enable searching of the data storage device 26, the apparatus 10 is 
further provided with a search engine 40 (FIG. 2). The search engine 40 is responsive 
to a request from a requester for credit information to access and search the data 
10 stored in the data storage device 26. The search engine 40 can be implemented by 

any known searching methodology. However, the search engine 40 is preferably 
constructed such that any responsive credit information output to the requester via 
output 42 does not disclose the identity of the lender that provided the credit 
information. Withholding the lender identification information associated with the 
15 credit in f ormation identified by the search engine 40 ensures that lenders providing 

information to the system are not put at a competitive disadvantage. 

In order to generate revenue for the entity operating the apparatus 10, the 

apparatus 10 is further provided with an accounting facility 50. The accounting 

facility functions to charge a search fee to the requester that initiated the search 

20 performed by the search engine 40. Preferably, the search fees exceed the usage fees. 

The difference between the search fees and the usage fees comprise a revenue source 

to the entity operating the apparatus 10. Preferably, the accounting facility 50 is 

structured to automatically debit and credit banking and/or credit card accounts of the 

users participating in the system. However, the accounting facility 50 could also be 
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structured to generate periodic invoices/statements for the participating users. These 
invoices/statements could be printed and mailed and/or sent via e-mail, as is 
conventional. 

The accounting facility 50 may also cooperate with the search engine 40 to 
5 credit usage fees to the provider of any information that is output by the output device 

42. The accounting facility 50 recognizes a data output, and automatically credits the 
account of the provider of the output information. 

The output device 42 can be implemented by any conventional device. For 
example, the output device 42 can be implemented by a monitor, a printer, and/or a 
10 communication device such as a modem. In the latter case, the output device 42 is 

preferably coupled to the Internet to enable a remotely located user to perform 
searches of the apparatus 10. 

Persons of ordinary skill in the art will readily appreciate that, although the 
user identifier 28, the data processing facility 30, the search engine 40, the accounting 
15 facility 50 and the evaluation generator 54 can be implemented by hardware or 

firmware, in a preferred embodiment, each of those elements are preferably 
implemented by software. Exemplary software for implementing those elements will 
now be described in connection with the flowcharts shown in FIGS. 4-7, 10, 12-14. 
Persons of ordinary skill in the art will further appreciate that, although for ease of 
20 explanation, the flowcharts illustrate and describe a series of steps in a particular 

temporal sequence, other temporal sequences and steps can be used to implement any 
part of the apparatus 10 without departing from the scope or spirit of the invention. 

FIGS. 4-5 show a general overview of the system for automatically 
exchanging credit information between the member and the apparatus 10. The 
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apparatus 10 receives incoming data from either a proprietary format, block 52, or 
from a format that already conforms to the format of apparatus 10 (block 54). If the 
incoming data is in a proprietary format, the data is transformed into distinct files for 
loading, matching the format of the apparatus 10 (block 56). Unknown record types 
5 are written to an error log, and incorrect administrative records will stop the loading 

process. The files are then loaded to the apparatus 10 and an error log is generated, if 
necessary (block 58). If the incoming data conforms to the format of the apparatus 
10, the data is split into distinct files for loading of the data into the staging area of the 
database (block 60). Unknown record types are written to an error log, and incorrect 
10 administrative records will stop the loading process. The files are then loaded to the 

apparatus 10 and an error log is generated, if necessary (block 62). 

Once the files are loaded, the fields located in the load files are processed and 
validated (block 64). Each field in each record is individually verified for its data 
type and for the presence of required fields and values. Records that fail to meet this 
15 criteria are not loaded in the staging database and are placed in the error log (block 

66). The sta gin g database records are then generated, and error log entries are made, 
if necessary (block 68). 

Next, the integrity of the data is validated, block 70, which includes ensuring 
that various data scrubbing rules are met, as well as the elimination of unknown 
20 records (block 72). Once this validation is performed, the staging database records 

are updated, and scrubbing queue records (i.e., suspect data) and error log entries are 
made, if necessary (block 74). 

Lessee matching is then performed, block 76, wherein records in the staging 

database are first matched internally within the member, and then matched to existing 
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records in the production database of apparatus 10, based on numerous fields of 
company criteria (block 78). Scrubbing queue records are then generated, block 80, 
and data transfer between the member load/scrubbing database and the apparatus 10 is 
performed (block 82). As shown in block 84, incoming data passes the automatic 
5 validation process (blocks 70 and 72), and the data is transferred to the production 

database of the apparatus 10 for viewing. If, however, incoming data does not pass 
the automatic validation process (blocks 70 and 72) and scrubbing errors are attached 
to the data (block 74), the records within this data are flagged as non-viewable and 
transferred to the production system to await future processing. 

10 Once the data is successfully transferred to the apparatus 10, production 

records are generated, block 86, and External data source matching is performed, 
block 88, wherein data that is transferred to the production system of apparatus 10 is 
automatically matched to the External data source database (block 90). Finally, 
production records are updated once this matching is performed, shown at block 92. 

15 Following is a more detailed discussion of the system as shown generally in 

FIGS. 4-6, which applies specifically to InfoLease™ systems by International Data 
Systems in Minnesota. Upon a member’s initial subscription to the system, the 
member will receive a setup program necessary to install software to communicate 
with the apparatus 10, shown generally in FIG. 6. To begin, the member will enter 
20 the member’s lease system address (block 94). Next, the member will enter a valid 

Unix Login ID (block 96). Finally, the member will enter a password for the 
aforementioned Login ID (block 98). 

Next, the member will collect and store its system data (block 100), wherein 
the appropriate files are moved to a /trap (i.e., temporary) directory on the member’s 
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Unix system. This directory will contain a copy of the member’s data so that the 
integrity of the member’s original data is not affected. The member then logs in to 
the apparatus 10 (block 102) and compiles and catalogs a setup program (block 104). 
The setup program is run at block 106. 

5 The setup program described above then performs various functions, shown 

generally in FIG. 7. First, multiple transfer files are downloaded from the apparatus 
10 to the member’s computer (block 108). These transfer files contain various 
transfer programs, the transfer file FTP directory, and the transfer file build directory 
and holding area. If, during the installation process, the transfer program cannot find 
10 the FTP or build directories, these directories are then recreated automatically. 

Second, various programs are copied from the apparatus 10 (block 110). 

These programs control the transfer and re-transfer of leasing information, the record 
maintenance (“MAINT”), the transfer menu (“MENU”), and the system account copy 
and/or update process. Finally, the MENU program is executed by the member 
15 (block 112). Now the member’s computer is set up to communicate with the 

apparatus 10, which will allow the member to exchange its leasing and credit 
information with the apparatus 10. Blocks 94-98 (in FIG. 6) are typically only 
performed the first time a member logs on to the apparatus 10. On subsequent visits 
to the apparatus 10, the file transfer process will skip from block 102 to block 112. 

20 Upon execution of the MENU program (block 112), a display becomes 

available as shown in FIG. 8. The member will then be able to choose from the 
selections that appear in the display. The first selection in FIG. 8, Control 
Maintenance, maintains the transfer control record to verify the integrity of the file 
transfer process between the member’s system and the apparatus 10. The second 


11 











29804/36569 


selection. Lease Transfer, builds the transfer file and executes the transfer of the 
member’s lease information to the apparatus 10 via Internet transfer or e-mail. The 
third selection, Lease Re-Transfer, runs the same program as the Lease Transfer, but 
bypasses the building of the transfer file. This option allows a retransmission of the 
5 file if problems with connecting to the Internet transfer server or the remote e-mail 

host are experienced. The fourth selection. Lease Transfer Status Inquiry, displays 
the log file from the last transfer attempt via a conventional Unix command. The fifth 
selection. Remove Prior Transfer Files, allows the member to remove prior transfer 
files from a transfer directory. Finally, the sixth selection. Copy to Another Account, 
10 allows a system administrator for the member to copy all of the necessary programs 

and files to another account. 

The MAINT program, referenced above, may also be executed by the 
member, wherein a display becomes available as shown in FIG. 9, which allows the 
member to maintain the transfer control record. The member will be able to choose 
15 from the selections that appear in the display. The Member Identifier selection 

represents an identifier that is assigned to the member. This identifier should be used 
in both the file names and on the records within each file. The Portfolio Identifier 
represents a member supplied identifier which indicates the specific system the files 
are coming from. Because members may run multiple systems, this identifier will 
20 prevent any confusion if duplicate customer IDs or lease numbers are used in the 

multiple systems. This identifier should be used in both the file names and records 
within the file. The Member Load Password is provided by the member and is used 
for verification of the file prior to processing. The Log E-Mail Address allows the 
member to have the build and transfer log from the Lease Transfer/Re-Transfer 
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processes (described in FIG. 10, below) e-mailed to the address upon completion of 
the transfer process. The Transfer Type tells the transfer program the type of transfer 
the member uses: (B)uild only, (E)-mail transfer, or (H) Internet transfer. The 
Destination E-Mail Address is used to transfer the file to the apparatus 10. This field 
5 is a required entry if the transfer type is “E” for an E-mail transfer. The Internet 

Transfer Name/IP Address selection represents the hostname or IP address used by 
Internet transfer to transmit the transfer file to the apparatus 10. This field is a 
required entry if the transfer type is “H” for an Internet transfer. The Internet Transfer 
Login ID represents the login ID used by the Internet transfer protocol to connect the 
10 Internet transfer host. This field is a required entry if the transfer type is “H” for an 

Internet transfer. The Internet Transfer Login Password represents the password used 
in conjunction with the login ID used by the Internet transfer protocol to connect the 
Internet transfer host. This field is also a required entry if the transfer type is “H” for 
an Internet transfer. The Test Mode (Y/N) selection forces the member to test the 
15 member ID, the portfolio ID (if it is not already loaded), and the member load 

password identifiers for the apparatus 10 from within the transfer program. This field 
should be reset to “N” after completing the initial testing of the transfer. The 
Maintain History (Y/N) selection maintains an archive of transfer files that should be 
deleted manually through the MENU program. If the transfer files are not deleted 
20 manually, only the most recent transfer file will be saved. The Transfer Run Default 

selection is used to load the defaults for the prompts within the transfer program of 
the apparatus 10. These fields are not required. The (S)leep, (I)mmediate selection 
loads the default to run the transfer program immediately or to sleep and run at a 
specified time. This field can be manually overwritten from the prompts within the 
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transfer program unless the transfer program prompts have been turned off. The 
Sleep Until hh:mm:ss selection allows the member to enter a valid time for the 
transfer process to wait to start processing the build and transfer fields if the sleep 
option is used. The Compress Transfer File selection allows for a faster file transfer 
5 via E-Mail or Internet transfer. The member can enter “Y” to Unix compress the 

transfer file prior to exporting the file to its destination, which will substantially 
reduce the size of the transfer file. The Prompts in Transfer Pgm selection allows the 
member to turn the transfer program prompts off and on. The Last Transfer Date field 
displays the last date the transfer process was started. The Last Transfer Start Time 
10 displays the last time the transfer process was started. This field can be set after any 

sleep commands are executed. Finally, the Last Transfer End Time displays the 
ending time of the last transfer process. 

The following section describes the data extraction process regardless of the 
member’s information and accounting system type. Members to the aforementioned 
15 apparatus are assigned an identifier that is used in both the file names and records 

within their file. This identifier will maintain the confidentiality of the member, so 
that its actual identity is not revealed in any search results. As shown in FIG. 10, to 
load data into the apparatus 10, the apparatus 10 extracts predefined records relating 
to payment history data from the members’ respective lease information and 
20 accounting systems 120, such as InfoLease™, into a payment history data file 122 

with the identifier included in the file name. The member lease information and 
accounting systems contain numerous records, such as asset master files, customer 
default master files, customer master files, lease payment history files, lease contract 
A/R address files, lease contract billing files, lease contract customer address files. 
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lease contract master files, lease payment cross-reference files, lease payment 
schedules, and control records. The data file 122 is then loaded via the Internet 
(preferably using the https protocol) to the apparatus 10, shown generally at 124. 

This is the Lease Transfer/Re-Transfer process referred to in FIGS. 8 and 9 above. 

5 The payment history data file 122 will typically contain numerous files, which are 

then compiled into a single payment history data file. This single payment history 
data file contains numerous records, such as a file header, type code detail, type code 
footer, customer/lessee detail, customer/lessee footer, lease/loan detail, lease/loan 
footer, lease/loan payment detail, lease/loan payment footer, and file footer. As 
10 shown in FIG. 11, the file header 126 contains the member identifier, which is used 

for verification prior to processing. The file header 126 should be the first record in 
the file. The type code detail record 128 provides type code translations for the 
various types of data fields that are included in the payment history data file 122. 

Such data fields may include the equipment type, which indicates what is being 
15 financed, the loan or lease type, which categorizes the actual loan or lease (operating 

lease, capital lease, leverage lease, or conditional sale or loan, etc.), the ownership 
type, which indicates the business type or ownership of the customer/lessee (S 
Corporation, Proprietorship, LLC, or Limited Partnership, etc.) and the purchase 
option, which categorizes the end of loan and/or lease options (fair market value, 

20 guaranteed purchase, or fixed purchase option, etc.). The type code footer 130 

indicates how many type code detail records 128 exist in the payment history data file 
122. The customer/lessee detail record 132 provides the main information about a 
single customer/lessee, and the customer/lessee footer record 134 indicates how many 
customer/lessee detail records 132 exist in the payment history data file 122. The 
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lease/loan detail record 136 provides common information about a loan and/or lease, 
such as the customer, original amount, payment amount, and status of the loan and/or 
lease at a certain point in time (i.e., delinquency and loss amounts). The payment 
history data file 122 may contain more than one lease/loan detail record 136 for a 
5 particular lease, as long as the “as of date” is different. For example, there may be a 

record for both the August and September delinquency status for a lease in the same 
payment history data file 122. The lease/loan footer record 137 indicates how many 
lease/loan detail records 136 exist in the payment history data file 122. The lease/loan 
payment detail record 138 provides common payment information about a loan and/or 
10 lease. The lease/loan payment footer 139 indicates how many lease/loan payment 

detail records 138 exist in the payment history data file 122. Finally, the file footer 
record 140 is included for verification purposes, to signal the end of the payment 
history data file 122. Accordingly, the file footer record 140 should be the last record 
in the file, so that the apparatus 10 knows the entire payment history data file 122 was 
15 received. In addition to the data described above, the payment history data may also 

include information such as the member’s account identification, the lessor’s 
customer identification for the customer, the lender’s loan and/or lease identification, 
the customer’s name, address, telephone number and SIC code, the loan and/or lease 
start date, the loan and/or lease amount, the current balance, the payment amount, the 
20 number of remaining payments, and the number of times the customer has been late in 

paying. In addition to the foregoing information, alternative customer names and 
addresses may be stored in the database, as well as the customer’s Taxpayer 
Identification Number (TIN) and credit bureau numbers. 
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Returning to FIG. 10, the apparatus 10 preferably includes a load database 142 
for buffering newly received records. There are at least two ways to load data into the 
load database 142: initial loading and incremental loading. The initial loading of 
payment history data by a member will usually include a large amount of information 
5 due to the length of time that the payment history data will cover. Accordingly, the 

initial loading is preferably performed by transmitting the payment history data files 
to the apparatus through use of the Internet transfer or on a CD. The apparatus 
provides detailed specifications to the member relating to how the data is to be 
derived and the format for transmitting the data to the apparatus. 

1 o The incremental loading of payment history data may be performed on a 

regular basis by each member. For incremental loading, members extract information 
about new leases that were booked during the time period since the last data load, 
loans and/or leases that remained active during the time period since the last data 
load, and loans and/or leases that were terminated during the time period since the last 
15 data load. Preferably, incremental loading is performed by transmitting the payment 

history data files through the Internet, but other methods may be used. 

The payment history data file 122 is preferably treated as a batch and includes 
the member identifier and control records for validating the file. A more detailed 
flow chart showing the process of uploading data to the apparatus is shown in FIG. 

20 12. As shown in FIG. 12, the process is initiated when the apparatus 10 receives a 

payment history data file (block 144). To maintain confidentiality for the system 
participants, the lender’s identification will not be disclosed to the member. This 
information will be collected, however, to facilitate data validation and verification. 
In addition, identification of the member who submits each payment history report 
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may be necessary to ensure that members are credited when information they supply 
to the system is inquired upon. To properly identify submitted information and avoid 
vandalism (e.g., submission of bad data), the user identifier 28 (FIG. 2) of the 
apparatus 10 first scans the file for a member identifier (block 146). If any data in the 
5 file does not have the appropriate identifier and is not recognized by the apparatus 10 

(block 148), the entire file is rejected (block 150). An error message is created and 
sent to the data submitter indicating that there were problems with the file (block 
152). A notation is then placed in an error log file (block 154). This updating of the 
error log is also shown at block 158 in FIG. 10. Control then returns to block 144 
10 until another file is received. 

If, at block 148, the user identifier 28 (FIG. 2) of the apparatus 10 determines 
that the file does have an appropriate identifier, the file is accepted (block 156) and 
passed to the data processing facility 30 (FIG. 2) for placement into the system 
database 26 (block 160 of FIG. 10). 

15 As mentioned above, the data processing facility 30 (FIG. 2) validates, edits 

and loads received files into the system database 26. Upon receipt of a payment 
history data file 122 = (FIG. 10 ), the data validator 32 of the data processing facility 30 
analyzes the file for customer transaction data, such as loan and/or lease data. If the 
file contains data on a customer that was previously loaded from a member (block 
20 164), that data is tested for validity (block 162). Customer data is tested by matching 

the business information of the customer (e.g., customer name, address, phone 
number, number of employees, etc.) with information contained in a general business 
information database, separate from the load database 142 of the apparatus 10 . 
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Different thresholds for triggering suspect customer data are set by individual 
members. 

Similarly, all transaction data that is loaded into the system database 26 (FIG. 
2) is also tested for validity (block 166). As part of the validation process for the 
transaction data, different thresholds for triggering suspect transaction data are set by 
individual members, and are based on different factors such as large time differences 
between records, records that contain payment amounts outside a maximum expected 
range, or records that appear on current records when they should have appeared on 
previous records. For example, if a payment that was overdue 90 days appears on a 
payment history report but did not appear on the previous payment history report as 
60 days overdue, that payment history data may be flagged as suspect. If there is 
suspect transaction data, as shown at 168, or suspect customer data, as shown at 170, 
that suspect transaction or customer data is stored in a scrubbing queue 172 for 
manual review and data cleansing. If there is good transaction data, as shown at 174, 
or good customer data, as shown at 176, that good lease or lessee data is stored in the 
system’s data repository 26. 

Returning to block 164 (FIG. 10), if the data processing facility 30 (FIG. 2) 
determines that the file contains data on a customer that was not previously loaded 
from a member, it initiates matching routines (block 178) to apply new payment 
history data to existing customers in the system, or to create new customers for 
payment history data that has no matching customer in the system. The same 
scrubbing routine described above is also performed on the matched or unmatched 
customer data. If there is unmatched customer data that is determined to be valid 
data, that data is sent and added to the system’s data repository 26, as shown at 180. 
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If there is matched customer data that is determined to be suspect data, that data is 
sent to the scrubbing queue 172, as shown at 182, where manual data cleansing is 
subsequently performed. 

The scrubbing routines described above are performed to remove or hold in 
5 suspense erroneous or suspect data, so that members to the system cannot query 

against them. During the scrubbing routines, suspect payment history data is reported 
on and can be modified by the system, both manually and automatically. As part of 
the manual data cleansing process, the records in the scrubbing queue 172 are checked 
manually by having a data consultant call the finance companies to verify the 
10 information in each record. The automated process occurs when the system has 

identified from a previous manual check that the record is incorrect and the system 
automatically changes the record to what it should correctly show. 

After the loading process is completed, the apparatus 10 maintains information 
about each batch of reports that are loaded, such as the member identification, the 
15 time and date of the transfer, the number of reports submitted, the number of error- 

free reports, and the number of errors. 

Members can inquire about a customer’s lease payment history by accessing 
the apparatus 10 and requesting data. The user accesses the apparatus 10 by entering 
a user name and password. As shown in FIG. 13, when a user name and password are 
20 submitted (block 200), the user identifier 28 scans the database 26 for a matching 

record (block 202). If a match is not found, the user is not recognized (block 204). 
The user identifier 28 will then return an error message (block 206) and log the failed 
access attempt. Control then returns to block 200. 
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If the user is recognized (block 204), the user identifier 28 records the date and 
time of the access along with the identity of the user accessing the apparatus 10 (block 
208). The user is then given permission to access the apparatus 10. 

The recognized user can initiate a search of the apparatus 10 by entering one 
5 or more of the following into a query request screen: the company’s name, address, 

telephone number, TIN, Owner’s SSN, or some other credit bureau identification 
number. As shown in FIG. 14, the search engine 40 uses the information provided by 
the member, including partial names and addresses, to attempt to find a match to the 
query request. In particular, when the search engine 40 receives the member query 
10 (block 220), it scans the payment history data within the system database 26 (block 

222). If a match is not found (block 224), the member is prompted to provide 
additional information, or to contact the system’s customer service for assistance 
(block 226). If any matches are found (block 224), the apparatus 10 will display the 
search results (block 228). The apparatus 10 will only provide members with a list of 
15 near matches (up to 24), to thereby preclude members from using the system to 

randomly search for lessees. The user is prompted to choose the desired company 
from the list of similars (block 230), which takes them to the confirmation/report 
selection screen (block 232). On this screen, the user chooses the desired report 
sections from the list of active sections for this company (block 234). The user is then 
20 required to “click” on the generate report button which confirms their intent to 

purchase the information. The system then generates the report to the screen (block 
238) and initiates the billing routine (block 240). 

If the user provides more data (block 226), control returns to block 222 where 
another search is performed. If no additional data is provided, control returns to block 
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220 without displaying the search results to the user so the user can optionally initiate 
a new search. 

If a company summary report is requested (block 234), the evaluation 
generator 54 (FIG. 2) performs predetermined mathematical analysis of the credit 
5 information developed in the search to develop a summary of that credit history 

information (block 236). This summary preferably includes a scoring of the 
borrower’s payment ability and certain benchmark statistics, such as high credit value, 
total loan and/or lease balance, total current payments, and the total number of times 
the customer was late in paying. Preferably, the developed summary is output to the 
10 requester along with the detailed search results (block 238). The search results 

preferably include the following pieces of information: the customer’s name, address, 
telephone number, SIC code, and for each loan and/or lease the customer has, the loan 
and/or lease start date, the loan and/or lease amount, the current balance, the payment 
amount, the number of remaining payments, and the number of times late and the 
15 amounts the customer has been late in paying. An example of a summary which 

could be generated by an evaluation generator 54 is shown in FIGS. 15 A-E. 

The payment history report screen is preferably read-only, although it may 
optionally be enhanced to permit members to sort the loan and/or lease records by 
different columns of information, such as the loan and/or lease start date, high credit 
20 value, current balance, payment amount, and number of remaining payments. If there 

is payment history data that is being disputed, it is flagged within the report. In 
addition, the customer’s responses to a disputed loan and/or lease are displayed if the 
loan and/or lease at issue appears on the payment history report. 
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The system automatically stores information about each inquiry, including the 
account and member who made the inquiry, the time and date of the inquiry, the 
information provided, the report sections requested, whether the inquiry was 
successful, and if successful the customer and loan and/or lease records found. This 
5 information enables system administrators to look for patterns of inquiry abuse, 

examine how the system is being used, and determine what types of problems 
members are having when they make inquiries that do not result in matches. This 
information also enables the system to charge members for their use of the system 
(block 240). 

10 In particular, whenever search results are displayed, the search engine 40 

(FIG. 2) invokes the accounting facility 50. The accounting facility 50 can be 
implemented by software as shown in FIG. 16. When invoked by the search engine 
40, the accounting facility 50 will charge a search fee to the user requesting the search 
(block 250) and, optionally, credit a usage fee to the user requesting the search (block 

15 252). If it is time to actually bill the users (block 254), the accounting facility 50 will 

automatically issue invoices and/or statements to the appropriate users (block 256). 

As mentioned earlier, block 256 can optionally be performed by automatically 
debiting and/or crediting the bank account(s) or credit card account(s) of the 
appropriate users. 

20 Preferably, blocks 254 and 256 are periodically called even when no searching 

is performed to ensure billing is performed on a predetermined cycle. 

Although certain apparatus constructed in accordance with the teachings of the 

invention have been described herein, the scope of coverage of this patent is not 

limited thereto. On the contrary, this patent covers all embodiments of the teachings 
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of the invention fairly falling within the scope of the appended claims either literally 
or under the doctrine of equivalents. 


24 





